第11章 制約理論
#エクストリームプログラミング
システム全体のスループットを確認する方法に制約理論(Theory of Constraints)というものがある
例えば、服の洗濯するときには以下のフローがあったとする
1. 洗濯機で45分かけて洗濯する
2. 乾燥機で90分かけて乾燥する
3. 15分かけてたたむ
このフローのボトルネックになる部分は乾燥機に時間がかかる(作業が集中しやすい)こと。洗濯機は終えたら、すぐに乾燥機に洗濯物を移動すればいいが、乾燥機は終えるまでに時間がかかってしまい、次の手順にすすめない
上記においては、制約理論におけるフローの制約は乾燥機となり、乾燥機のボトルネックを改善していかないといけない
制約理論では、システムが同時に制約が1つ(もしくは2つ)があると考え、改善するために制約を見つけることから始める
そして、その制約が最大限に稼働しているかを確認し、キャパシティを増やす苦か、制約以外の負荷を軽減するかを考える
上記の例だと、服を乾かすときには乾燥機+ベランダに服を干す、乾燥機付き洗濯機を使うという方法などがある
制約は一つ改善すると、また別の制約が発生する
ソフトウェア開発において機能開発においてドキュメント管理に時間がかかったり場合は、ドキュメント管理が制約になり、対策していく必要がある
組織の改善する場合にも制約理論が活かすことができ、その場合は全体的なスループットを考えて取り組むこと。
特定の個人が制約と見なしても、反対されて改善ができない可能性がある。全体を俯瞰をして、価値を提供できるような制約を探すこと
制約はソフトウェア開発以外の要素になりえることもある。
XPを適用させ品質や生産性が上がると、制約はソフトウェア開発以外になり、チームを解散させられることがある。XPの適用には経営幹部やチーム外の人たちの理解が必要になる